REMARKS 

SUMMARY : 

The subject application previously set forth claims 1-20, all of which are presently 
cancelled. New and currently active claims correspond to claims 21-32, of which claims 
21 and 27 are independent claims. 

The detailed action OF August 23, 2004 set forth rejection grounds for original 
claims 1, 2, 6, 7, 11, 12, 16 and 17 under 35 U.S.C. § 102(a) as being anticipated by 
U.S. Patent No. 5,91 1,069 (Beard ). Original claims 3, 5, 8, 10, 13, 15, 18 and 20 were 
rejected under 35 U.S.C. §103(a) as being unpatentable over Beard in view of U.S. 
Patent No. 4,481,577 (Forson). Original claims 4, 9, 14 and 19 were rejected under 35 
U.S.C. § 103(a) as being unpatentable over Beard in view of U.S. Patent No. 5,761,407 
( Benson et al. ) 

Responses to and traversals of each of the above rejections as set forth below in 
the order as presented by the Examiner in the August 23, 2004 Office Action. 
Comments are also presented which point out various patentable distinctions for new 
claims 21-32 relative to the aforementioned previously cited references. 

Withdrawal of the previous rejections and allowance of all new claims 21 through 
32 are respectfully requested. 

35 U-S.C, §102(b) Rejection (Claims 1-2, 6-7, 11-12 and 16-17): 

New independent claim 21 is directed to a method of providing exception 
handling for a computer program, and independent claim 27 is directed to a related 
exception handling system. Both claims set forth respective features (i^, either steps 
or elements) related to various specific aspects of the present exception handling 
technology. The features of independent claim 21 (and similar features of claim 27) 
involve establishing a plurality of classes of exception types, providing an exception 
dictionary used to list instances of each exception type, throwing an exception, 
identifying an exception type for the exception using the exception dictionary, and 
providing an exception notice for the exception. The plurality of exception types 
provided for and listed in the exception dictionary include application exceptions, 
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system exceptions and validation exceptions. 

Numbered page 2 of the August 23, 2004 Office Action set forth that Beard 
discloses all elements of previous original claim 1, including features related to 
establishing a plurality of exception types, providing an exception notice for an 
exception, and determining an exception type. Applicants respectfully submit that 
several aspects set forth in present claims 21 and 27 are not disclosed in, nor 
suggested by, Beard . 

Beard does not disclose providing and identifying exception classes that 
specifically include application exceptions, system exceptions and validation 
exceptions. It is important to distinguish among such types of exceptions because they 
must be caught and recovered from in respectively different fashions, depending on 
which determination is made. See page 9, lines 11-17 of the original specification, 
which state: 

Validation exceptions should be caught directly by the 
method where object-to-object communication is taking place. 
Every correction algorithm for a validation exception is unique. 
Therefore, it must be handled in the method which is throwing the 
validation exception. [In contrast, ajpplication and system 
exceptions should be propagated in special places, where they can 
be handled in the usual way [Le., a conventional fashion]. Both of 
these exceptions [system and application exceptions] appear 
because of unpredictable events, which should be handled at a 
central place for better code and maintenance as well as 
extendability. 

Beard does disclose in col. 9, lines 35-42 that exceptions are labeled with a 
string that indicates the type of exception that has occurred, and that for each type of 
exception a class is defined. Classes disclosed in Beard are generally referred to by 
variables, such as ClassA-ClassE, respectively. Therefore, Beard plainly fails to 
disclose the establishment and identification of thrown exceptions as specific types, 
including one of an application, system, or validation exception. 
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Beard is not concerned with specific types of exceptions because Beard is not 
concerned with features for capturing or recovering from exceptions. Regarding 
exceptions, Beard is only concerned with thrown exceptions and "handling the 
exchange of information" about exceptions within an object-oriented program. 

As such, Beard : (1 ) fails to focus on the same technical needs and deficiencies 
as the present subject matter, and (2) fails to disclose all elements of present 
independent claims 21 and 27. 

Furthermore, since Beard only makes reference to throwing of exceptions and 
abjectly lacks reference to any features for "capturing" or processing to recover from 
exceptions. Beard also fails to disclose all elements of present respective dependent 
claims 22 and 28. 

Numbered page 2 of the August 23, 2004 Office Action equated "capturing" an 
exception as set forth in original claim 1 to "detecting" an exception. Such comparison 
is respectfully inaccurate. As set forth in the present original specification on page 9, 
signaling that an exceptional condition has occurred (Le., detecting an exception) is 
known as "throwing" an exception. Recovering from an exceptional state is known as 
"catching" an exception. Beard provides no features for how to process an exception 
after it is detected, and thus fails to disclose or suggest features related to capturing an 
exception as set forth in present claims 22 and 28. 

Since Beard does not disclose aspects related to subsequent processing or 
capturing of exceptions after detection of such. Beard also fails to disclose or suggest 
the elements set forth in present respective claims 23-24 and 29-30. The processing 
features set forth in claims 23-24 and 29-30 also require the determination of whether 
an exception is a validation exception. Since validation exceptions are not disclosed in 
Beard, such additional aspect of claims 23-24 and 29-30 is also not disclosed in or 
suggested by Beard . 

Based on the present amendments and the remarks herein. Applicants 
respectfully request withdrawal of the rejections based on Beard and allowance of 
present claims 21-32. 
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35 U.S.C, §103(a) Rejection (Claims 3, 5, 8, 10, 13, 15, 18 and 20): 

The remarks in the above section discuss several features that are not disclosed 
in nor suggested by the base reference Beard . The Examiner aptly notes that there are 
several other features that Beard also fails to disclose (or to suggest). More 
particularly, the August 23, 2004 Office Action helpfully and correctly notes that Beard 
fails to disclose using an exception dictionary. However, such Office Action further 
asserts that U.S. Patent No. 4,481 ,577 (Forson) allegedly cures such deficiency of the 
base reference Beard by disclosure of an indexed file and dictionary set of definitions. 

Applicants respectfully submit that features for providing an exception dictionary 
and for identifying an exception type as one of a system, application or validation 
exception using the exception dictionary is not disclosed in Forson nor suggested by 
Forson . Therefore, as a matter of law, Forson can not cure the significant deficiencies 
of the base reference Beard already noted by the Office Action. 

Forson discloses a method of operating a computer system in which customized 
error messages are stored in an indexed file, some having token words, and a ; 
dictionary list of definitions for all token words is developed. The type of dictionary 
disclosed in Forson is not an exception dictionary and is used in a completely different 
fashion than the exception dictionary features set forth in claims 21 and 27. Moreover, 
the error messages referred to herein should not be equated to exceptions, as was 
equated by the Examiner - in contrast, these are different phenomena. 

Referring to claim 1 of Forson, the dictionary disclosed in such reference is used 
to permit customized messages to the operator of a computer system. When a 
message has certain identifiable "token words", a dictionary may be used to retrieve 
definitions for such token words so that the message can be provided with a complete 
meaning. Such error messages are implemented according to Forson instead of 
conventional error numbers, for the convenience of a user so that such users do not 
have to take a message number and then consult a manual in order to obtain a definite 
meaning to the message (see col. 1 , lines 15-20 of Forson). 

The technology disclosed in Forson is not related to a dictionary used to identify 
exceptions types, much less specific exceptions such as system, application and 
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validation exceptions, as affirnnatively set forth in present independent claims 21 and 
27. As such, Forson fails to cure the above-noted important deficiencies of Beard , 
wherefore neither Beard nor Forson, singularly or in combination, sets forth or suggests 
all elements of present independent claims 21 and 27. As such. Applicants respectfully 
submit that independent claims 21 and 27 are patentable over such references. 

Applicants further submit that the USPTO position fails to set forth a valid 
suggestion or motivation to combine Beard and Forson references. The August 23, 
2004 Office Action sets forth on numbered page 3 "that one of ordinary skill in the art 
would have been motivated to combine the teachings of Beard and Forson because 
this would have allowed customization of exception notice without availability of the 
source code". 

Forson does not deal with exceptions, and as discussed above, the dictionary 
features employed in such reference are for different reasons than those set forth in 
present independent claims 21 and 27. Furthermore, Beard does not teach features for 
how to process exceptions-only how to characterize them. Therefore, Applicants 
submit that such characteristics actually teach away from any combination of Beard and 
Forson references. 

Accordingly, as a matter of law, respectfully there can be no proper suggestion 
or motivation to make the combination proposed by the USPTO position. 

35 U,S,C. §103(3) Rejection (Claims 4, 9, 14, 19): 

Prior claims 4, 9, 14 and 19 stand rejected under 35 U.S. 0. § 103(a) as being 
unpatentable over Beard in view of Benson et al. As previously noted, Beard fails to 
disclose many features of the present active claims. Applicants submit that Benson et 
aL also fail to cure those deficiencies. 

Present independent claims 21 and 27 respectively set forth features for 
establishing and identifying exception types as one of a system, application or 
validation exception, using an exception dictionary. Applicants submit that these 
features of independent claims 21 and 27 are also not disclosed in Benson et al., and 
thus such claims should be allowed as patentable over the proposed combination of 
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references. Furthermore, the subject matter set forth in respective claims 23-26 and 
29-32 is also not disclosed in or suggested by Benson et al. 

Applicants further note that the August 23, 2004 Office Action compares the 
"validation exceptions" of the present subject matter to a "valid" exception as referenced 
in Benson et al. In actuality, Benson et al, merely refers to the determination of whether 
"exception_cause pointer 340 is Mill (i.e., does not have a valid value)". ( See col. 8, 
lines 20-23 of Benson et al .) Valid or recognizable values for a pointer variable is not 
the same thing as an exception type, much less a validation exception. As such, the 
USPTO's characterization of Benson et al. respectfully is inaccurate in that regard. 

Applicants respectfully submit that Beard and Benson et al. fail to singularly or in 
combination disclose or suggest all elements set forth in present claims 21-32, and as 
such allowance of such claims is respectfully requested. 

CONCLUSION : 

In light of the foregoing amendments and for at least the reasons set forth above, 
Applicants respectfully submit that the present application, including claims 21-32, is in 
complete condition for issuance of a formal Notice of Allowance, and action to such 
effect is earnestly solicited. The Examiner is invited to telephone the undersigned at his 
convenience should only minor issues remain after consideration of this response in 
order to permit early resolution of same. 

Respectfully submitted, 

DORITY& MANNING, 
ATTORNEYS AT LAW, P.A. 

Date: April 22. 2005 

RICHARD M.^MOOSE 
R6g. No.: 31.226 
Customer ID No.: 22827 
Telephone: (864)271-1592 
Facsimile: (864) 233-7342 
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